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ABSTRACT 

Army  vehicles  are  complex  due  to  various  on-board  mission  critical  communication  devices.  The  Army 
cannot  afford  unreliable  software  to  interact  between  the  devices.  The  Army  vehicle  software’s  reliability  is 
influenced  by  multiple  factors  during  or  prior  to  its  development.  Using  complex  statistical  and  mathematical 
models,  software ’s  reliability  can  be  predicted,  but  it  is  dependent  on  the  accuracy  and  context  of  the  historical 
software  failure  data.  The  cost  of  developing  such  complex  models  does  not  yield  a  good  return  on  investment. 
The  data  collection  process  to  use  these  models  is  very  difficult  and  time  consuming.  In  this  paper,  we  propose 
reliability  metrics  based  on  the  current  software  development  and  design  process  factors.  We  also  propose  a 
fuzzy  logic  based  software  reliability  prediction  algorithm  using  the  proposed  reliability  metrics. 


INTRODUCTION 

Software  reliability  is  one  of  the  growing  challenges  for 
the  on-board  devices  in  an  Army’s  combat  vehicle  (CV). 
During  combat  missions,  soldiers  perform  complex 
operations  using  the  devices.  Each  device  has  its  own 
software  and  we  refer  to  it  as  Army  vehicle  software  (AVS). 
Combat  command  and  control,  and  vehicle  management  are 
some  examples  of  AVS.  An  AVS  performs  its  intended 
functions  when  needed.  This  allows  defending  against  the 
enemy  threats  and  protecting  the  soldiers.  Therefore,  AVS 
reliability  is  a  key  factor  for  successful  missions. 

An  AVS  is  considered  reliable  when  it  exhibits  all  its 
designed  features  with  no  defects  at  all  times  when  it  is 
operated  in  multiple  predefined  environments  and 
conditions.  We  use  the  term  AVS  reliability  to  refer  to  a 
probability  of  defect-free  condition  for  a  given  AVS.  As  the 
probability  of  defects  increases,  the  AVS  reliability 
decreases. 

Normally,  testing  reveals  software  defects  and  the 
developers  correct  them  before  it  is  used  in  practice.  This 
process  assures  that  the  software  is  reliable  when  it  is  used  in 
a  combat  mission.  However,  fixing  the  defects  after  they  are 
found  during  testing  is  costly;  it  is  always  better  to  apply 
efficient  techniques  during  early  development  phases  and 
avoid  future  defects  in  the  software.  For  early  development 
phases,  researchers  have  proposed  several  complex 
mathematical  and  statistical  techniques  to  predict  the 
probability  of  future  defects  in  the  software.  These 
techniques  require  skilled  resources  to  use  them.  The  Army 
tends  to  react  to  a  dynamic  situation  and  they  need  easy  to 
understand  software  reliability  prediction  techniques. 

Multiple  factors  during  a  software  development  process 
influences  AVS  reliability.  The  Army  pays  considerable 
attention  to  predict  AVS  reliability  using  easy  to  understand 


techniques.  The  AVS  reliability  measures  software  quality. 
Ensuring  AVS  reliability  is  absolutely  essential  [1]. 

Software  architects  develop  IT  architecture  documents 
(IT AD)  during  early  design  phases  of  an  AVS  development 
project.  IT  AD  reflect  how  the  software  will  be  implemented 
and  tested.  Therefore,  ITAD  captures  necessary  details  for  a 
successful  software  development  project.  We  can  investigate 
ITAD  and  formulate  reliability  metrics  and  then  use  them  to 
develop  AVS  reliability  prediction  techniques. 

In  this  paper,  we  propose  the  following: 

1.  Deriving  AVS  reliability  metrics  from  ITAD. 

2.  AVS  reliability  prediction  algorithm  using  fuzzy  logic 
and  the  derived  AVS  reliability  metrics. 

Our  research  is  in  its  initial  stages.  In  this  paper,  we 
introduce  our  approach  and  an  initial  solution  to  predict 
AVS  reliability.  We  describe  the  proposed  solution  in  this 
paper  using  an  example  dataset  that  we  developed  to 
introduce  the  concept.  We  are  in  the  process  of  validating 
our  work  for  a  practical  AVS  development  project. 

RELATED  WORK 

Most  of  the  architecture  related  predictions  surveyed  in  [2] 
are  dependent  on  the  software  structure  or  the  type  of 
modeling  languages  used. 

Mohanta  et  al.  provide  an  approach  in  [3]  to  derive  design 
metrics  and  use  them  in  a  Bayesian  Belief  Network  to 
predict  software  reliability.  In  this  approach,  the  prediction 
accuracy  depends  on  the  accuracy  of  how  well  the  design 
metrics  are  derived.  In  many  cases,  it  is  overkill  and 
restrictive. 

Wang  et  al.  recommend  a  state  model  framework  in  [4] 
using  software  architecture  as  a  basis  for  reliability 
prediction.  In  this  approach,  designers  create  a  Unified 
Modeling  Language  (UML)  state  model  for  individual 
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components  of  a  software  program  and  then  solve  a  Markov 
Chain  process  problem  to  predict  reliability.  Although  this  is 
a  good  approach,  dissecting  the  UML  architecture  to  identify 
its  structure  to  evaluate  future  problems  is  cumbersome  and 
error  prone.  It  also  has  a  dependency  on  the  type  of 
architecture  style  used  to  document  software  architecture. 

Goseva-Popstojanova  et  al.  propose  a  prediction  method 
[5]  using  component  interaction  within  software 
architectures.  This  method  is  based  on  analytical  approaches 
using  control  graphs.  Possible  execution  paths  within 
software  programs  are  also  used  to  predict  reliability. 
Identifying  and  analyzing  the  architecture  construct  is  time 
consuming  and  complex.  It  also  depends  on  the  style  used  to 
develop  software  architectures. 

Gokhale  et  al.  provide  a  framework  for  predicting  software 
reliability  [6]  using  composite  models  built  from  individual 
architecture  components  and  their  failure  behavior.  A 
prediction  using  this  method  is  accurate  only  when  one 
understands  all  the  component  interfaces  and  their  failure 
behaviors.  The  model  used  in  this  approach  is  too  analytical 
and  it  is  very  hard  to  collect  data  and  process  it  to  predict 
reliability. 

Nagappan  et  al.  provide  a  list  of  metrics  [7]  for  early 
software  tests  and  reliability  early  warning.  But  most  of  the 
metrics  are  derived  after  the  software  and  test  cases  are 
written.  So,  the  early  prediction  here  only  serves  to  predict 
reliability  before  the  software  is  fielded  and  used  in  practice. 

Smidts  et  al.  recommend  a  fault  tree  based  Bayesian 
quantification  framework  [8]  to  evaluate  software  reliability 
using  software  functional  architectures  which  represent  both 
functional  and  non-functional  requirements.  This  framework 
concentrates  on  studying  or  experimenting  with  software 
which  is  already  developed.  This  cannot  be  used  for  early 
predictions. 

Kong  et  al.  provide  a  cause  and  effect  Graphing  Analysis 

[9]  approach  for  early  software  reliability  prediction  by 
identifying  errors  in  the  software  requirements  specification 
(SRS)  document.  Every  SRS  document  is  written  differently, 
and  this  method  does  not  provide  any  techniques  to  identify 
defects  in  terms  of  incompleteness,  inconsistencies, 
ambiguities,  and  redundancies  in  each  software  requirement. 

Yacoub  et  al.  propose  a  scenario  based  reliability  analysis 

[10]  technique  for  component-based  software  using  the  path- 
based  approach  introduced  in  [5].  This  approach  models 
component  interactions  using  a  component-dependency 
graph.  This  technique  is  too  analytical  and  the  complexity 
grows  as  the  number  of  components  within  the  software 
increases.  Furthermore  the  data  collection  process  is 
cumbersome. 


AVS  RELIABILITY  METRICS 

IT  AD  captures  the  information  required  to  transform  user 
requirements  into  tangible  implementation.  Some  IT  AD  are 
pure  text  documents  and  some  are  built  using  modeling 
languages  such  as  UML.  IT  AD  describes  requirements 
realization  without  providing  low  level  implementation 
details.  The  developers  use  IT  AD  for  developing  specific 
solution  designs. 

At  any  point  of  time  during  a  software  development 
project,  any  person  with  ordinary  computer  skill  can  take  a 
snapshot  of  information  from  IT  AD  and  derive  fault 
handling  (F)  mechanisms,  data  handling  (D), 
interoperability  (I),  and  configurability  (C)  details 
documented  in  the  IT  AD. 

AVS  project  managers  can  use  the  derived  ‘D’,  T,  4C’, 
and  ‘F’  values  as  metrics  at  any  phase  of  an  AVS 
development  project  and  then  use  them  to  predict  AVS 
reliability.  Project  managers  can  rectify  issues  and  predict 
reliability  again  to  determine  if  the  reliability  has  improved. 

We  describe  how  to  derive  AVS  reliability  metrics  using 
IT  AD  information  in  next  few  sections. 

Data  handling  (D) 

We  can  quantify  data  handling  to  represent  the 
understanding  of  the  required  data  and  its  characteristics, 
and  the  test  cases  planned  for  them.  Using  this,  we  can 
determine  the  impact  of  ‘D’  on  AVS  reliability.  As  the  ‘D’ 
value  calculated  from  (1)  increases,  the  AVS  reliability 
decreases. 


D  =  3-( 


Do 


D, 


Dx 


—  ) 
Dx 


(1) 


Where, 

Di  =  required  number  of  distinct  data  elements. 

D2  =  number  of  distinct  data  elements  captured  with 
necessary  details. 

D3  =  number  of  distinct  data  elements  that  have  captured 
required  data  characteristics. 

Ti  =  total  test  cases  for  all  the  data  elements.  It  is 
calculated  using  (2). 


(2) 


Where,  Ti7  =  number  of  test  cases  that  are  planned  for 
testing  all  data  characteristics  per  data  element.  I.e.,  every 
data  element  must  have  at  least  one  test  case  planned  for 
every  data  characteristic.  Nc  =  total  number  of  data 
characteristics.  I  =  Ith  data  element  in  D1?  and  i=  ith  data 


Software  reliability  prediction  for  Army  vehicle. 
UNCLASSIFIED:  Dist  A.  Approved  for  public  release 
Page  2  of  9 


characteristic  in  Nc.  For  example,  assume  Nc  =  3  and  Dx  =  3, 
Then  the  Tm  can  be  represented  as:  Till,  T112,  T113, 
T121,  T122,  T123,  T131,  T132,  and  T133.  For  the  1st  data 
element,  if  the  1st  data  characteristic  has  a  test  case  planned, 
then  Tm  takes  the  value  of  1  else  it  takes  the  value  of  0. 
Similarly  all  other  Tixx  can  be  calculated. 

The  most  important  data  characteristics  are:  processing 
requirements,  data  format,  the  security  constraints,  data  size 
limitations,  and  the  data  storage  requirements. 
Understanding  the  data  elements  during  early  phases  of  an 
AVS  development  improves  the  quality  of  AVS  design,  and 
it  reduces  future  defects.  If  fewer  data  elements  are  known 
and  fewer  test  cases  are  planned  than  the  actual  required  data 
elements,  then  ‘D’  poses  a  major  negative  impact  on 
achieving  AVS  reliability.  Each  required  data  element  with 
its  details  has  to  be  known  and  should  have  at  least  one  test 
case  planned  to  test  each  of  the  data  characteristics.  This 
avoids  any  future  surprises. 


T3  =  total  test  cases  planned  for  testing  all  the  details  for 
all  the  outputs.  It  is  calculated  using  (5). 


T,=T 


A? 


(5) 


Where,  T2i  and  T3I  are  the  number  of  test  cases  planned  for 
testing  all  the  details  per  input  and  output,  respectively.  I.e., 
every  input  and  output  must  have  at  least  one  test  case 
planned  for  every  detail.  Ni  and  N0  are  the  total  number  of 
input  and  output  details,  respectively.  I  =  Ith  input  in  I,  and 
Ith  output  in  Oi,  respectively.  i=  ith  detail  in  Nj  and  ith  detail 
in  N0,  respectively.  For  the  Ith  input,  if  the  1st  detail  has  a  test 
case  planned,  then  T2n  takes  the  value  of  1  else  it  takes  the 
value  of  0.  The  same  rule  applies  toT311  also.  Similarly  all 
the  other  T2xx  and  T3xx  can  be  calculated. 


Interoperability  (I) 

Based  on  the  IEEE  definition,  interoperability  is  the 
capability  of  an  AVS  to  exchange  and  use  data  in  an 
operating  environment  within  predefined  access  restrictions. 
An  interoperable  AVS  is  expected  to  understand  all  the 
available  interfaces  when  exchanging  data  with  other  AVSs. 
This  capability  enables  an  AVS  to  produce  reliable 
operations. 

We  can  quantify  interoperability  to  represent  the 
understanding  of  the  required  inputs  and  outputs,  and  the  test 
cases  planned  for  them.  Using  this,  we  can  determine  the 
impact  of  T  on  AVS  reliability.  As  the  T  value  calculated 
from  (3)  increases,  the  AVS  reliability  decreases. 


1  = 


T2+T4+  ts 
h 


0, 


r,  +  T6  +  T10  ' 

0!  J 


(3) 


Where, 

11  =  required  number  of  distinct  inputs. 

12  =  number  of  distinct  inputs  captured  with  necessary 
details. 

Oi  =  required  number  of  distinct  outputs. 

02  =  number  of  distinct  outputs  captured  with  necessary 
details. 

T2  =  total  test  cases  planned  for  testing  all  the  details  for 
all  the  inputs.  It  is  calculated  using  (4). 


N. 


(4) 


T4  =  number  of  distinct  inputs  planned  for  testing  its  event 
logging. 

T6  =  number  of  distinct  outputs  planned  for  testing  its 
event  logging. 

T8  =  number  of  distinct  inputs  planned  for  testing  its  fault 
handling. 

T10  =  number  of  distinct  outputs  planned  for  testing  its 
fault  handling. 

An  AVS  may  have  one  or  many  input  sources  and  one  or 
many  output  destinations.  The  complete  knowledge  of  the 
following  reduces  defect  rates  and  increases  AVS  reliability: 

1 .  From  where  are  the  inputs  received  and  to  where  will 
the  outputs  be  delivered? 

2.  The  security  constraints  between  the  input  sources  -> 
AVS  and  AVS  ->  output  destinations. 

3.  The  transport  mechanism  for  all  inputs  and  output 
deliveries  e.g.,  frequency,  mode  of  initiation 
(automatic  push  or  pull). 

Understanding  the  inputs  and  outputs  early  in  the  design 
phase  improves  the  quality  of  AVS  design  and  development, 
and  it  reduces  future  defects.  If  fewer  inputs  or  outputs 
details  are  known  and  fewer  test  cases  are  planned  than  the 
actual  required  inputs  or  outputs,  then  the  T  poses  a  major 
negative  impact  on  achieving  AVS  reliability.  Each  required 
input  and  output  with  its  details  has  to  be  known  and  should 
have  at  least  one  test  case  planned  to  test  each  of  the  details. 
This  avoids  any  future  surprises. 

Configurability  (C) 

We  can  quantify  configurability  to  represent  the 
configurability  planned  for  each  data  elements,  inputs,  and 
outputs,  and  the  test  cases  planned  for  them.  Using  this,  we 
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(7) 


can  determine  the  impact  of  ‘C’  on  AVS  reliability.  As  the 
4C’  value  calculated  from  (6)  increases,  the  AVS  reliability 
decreases. 


A  +  A  c2  +c4  ^  T1  +Tn 
v  A  A  y 


(6) 


Where, 

Ci  and  C2  are  the  number  of  distinct  inputs  and  outputs, 
respectively  planned  for  configurable  event  logging. 

C3  and  C4  are  the  number  of  distinct  inputs  and  outputs, 
respectively  planned  for  configurable  fault  handling. 


T5  and  T7  are  the  number  of  distinct  inputs  and  outputs, 
respectively  planned  for  testing  its  configurable  event 
logging. 

T9  and  Tn  are  the  number  of  distinct  inputs  and  outputs, 
respectively  planned  for  testing  its  configurable  fault 
handling. 


Event  logging  mechanisms  minimize  confusion  in  dealing 
with  operational  faults.  Configurable  event  logging  enables 
the  users  or  the  maintainers  to  understand  what  really  went 
wrong  or  why  a  specific  scenario  executed  when  something 
else  was  expected.  When  developers  or  testers  exercise  this 
feature,  it  enables  them  to  understand  and  fix  problems 
correctly.  It  enhances  the  defect  removal  process  and 
increases  AVS  reliability. 

If  configurability  is  planned  for  each  of  the  data  elements, 
inputs,  and  outputs,  it  enables  an  AVS  to  operate  in  multiple 
operating  environments  and  conditions.  If  no  configurability 
is  planned,  there  is  no  easy  way  to  allow  it  to  work  in 
multiple  operating  environments  without  changing  the  code. 
Using  configurability  in  an  AVS  improves  the  quality  of 
AVS  design  and  development,  and  it  reduces  the  abrupt 
failures  when  it  is  operated  in  an  unknown  environment  for 
which  no  code  exists.  If  fewer  configurability  contingencies 
are  planned  and  fewer  test  cases  are  planned  than  the  actual 
required  inputs  or  outputs  or  data  elements,  then  4C’  poses  a 
major  negative  impact  on  achieving  AVS  reliability.  Each 
required  input,  output,  and  data  element  with  its  details  has 
to  be  planned  for  configurability  and  should  have  at  least 
one  test  case  planned  to  test  each  configurable  option.  This 
avoids  any  future  surprises  and  problems. 

Fault  handling  (F) 

We  can  quantify  fault  handling  to  represent  the  fault 
handling  mechanisms  planned  for  each  data  elements,  input, 
and  output,  and  the  test  cases  planned  for  them.  Using  this, 
we  can  determine  the  impact  of  4F’  on  AVS  reliability.  As 
the  ‘F’  value  calculated  from  (7)  increases,  the  AVS 
reliability  decreases. 


F  =  6- 


Et  +Ft 


V  7i 


^2  7*2  _j_  A  |  Ao 

Ox  A  Ox  y 


Where, 

Ei  =  number  of  distinct  inputs  planned  for  event  logging. 
Fi  =  number  of  distinct  inputs  planned  for  fault  handling. 


E2  =  number  of  distinct  outputs  planned  for  event  logging. 
F2  =  number  of  distinct  outputs  planned  for  fault  handling. 


T8  =  number  of  distinct  inputs  planned  for  testing  its  fault 
handling. 

T10  =  number  of  distinct  outputs  planned  for  testing  its 
fault  handling. 


Fault  handling  mechanisms  allow  users  to  get  graceful 
notifications  during  a  failure  through  readable  messages 
instead  of  ending  the  program  abruptly.  Using  proper  fault 
handlers  indicates  problem  areas  and  the  reasons  for  it.  This 
allows  users  to  take  corrective  actions  to  increase  the 
reliability  of  AVS  operations  e.g.,  when  the  user  enters 
invalid  data  in  an  AVS,  instead  of  ending  the  AVS  operation 
abruptly,  a  fault  handling  mechanism  in  an  AVS  notifies  the 
user  to  rectify  the  data  and  allow  re-execution  of  the 
operation.  This  allows  successful  operation  and  increases 
AVS  reliability. 

If  fault  handing  mechanisms  are  planned  for  each  of  the 
data  elements,  inputs,  and  outputs,  it  enables  developers  to 
understand  the  details  of  when  and  how  a  fault  happens.  If 
no  fault  handling  is  planned,  there  is  no  easy  way  to 
gracefully  inform  the  user  of  any  faults  or  errors.  Using  fault 
handling  improves  the  quality  of  AVS  design  and 
development,  and  it  reduces  abrupt  failures.  If  fewer  fault 
handlings  are  planned  and  fewer  test  cases  are  planned  than 
the  actual  required  inputs  or  outputs  or  data  elements  then 
the  4F’  poses  a  major  negative  impact  on  achieving  AVS 
reliability.  Each  required  input,  output,  and  data  element 
with  its  details  has  to  be  planned  for  fault  handling  and  they 
should  have  at  least  one  test  case  planned  to  test  each  fault 
handling  mechanism. 

All  the  parameters  described  above  are  simple  to 
understand  and  a  person  with  no  special  skills  can  gather 
them  very  easily  from  reading  IT  AD. 

In  the  next  section,  we  describe  how  the  metrics  defined  in 
this  section  can  be  used  to  predict  AVS  reliability.  For  a 
given  AVS  development  project,  all  four  metric  elements 
have  to  be  measured  or  assessed.  Each  metric  element  has  a 
default  value  as  shown  in  Table  1. 


Table  .1  Metric  elements  default  values 
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Metric  Element 

Default  Value 

Data  Handling  (D) 

3 

Interoperability  (1) 

S 

Fault  Handling  (F) 

6 

Configurability  (C) 

S 

AVS  RELIABILITY  PREDICTION  ALGORITHM 

In  this  section,  we  describe  our  proposed  AVS  reliability 
prediction  algorithm.  This  algorithm  is  based  on  fuzzy  logic 
and  it  uses  AVS  reliability  metrics.  Figure  1  depicts  an 
outline  of  the  prediction  algorithm  for  a  given  AVS 
development  project. 


Figure.  1  AVS  Reliability  prediction  algorithm  outline 
The  Algorithm  is  as  follows: 

1.  For  every  AVS  project 

2.  Docs  C-  Collect  ITAD( ) 

3.  Begin 

4.  Data  Populate  Data  (Docs) 

5.  MetricData  Readlnputs  (Data) 

6.  D  Compute  DataHandling(Metricdata) 

7.  I  Compute  Interoperability  (Metricdata) 

8.  F  C-  Compute  FaultHandling(Metricdata) 

9.  C  <-  Compute  Configurability  ( Metricdata ) 

10.  Fuzzy_inputs  <-  fuzzify  (D,I,F,C) 


1 1 .  Fuzzy_rules  <-  GetFuzzy Rules  () 

12.  Y  <-  AppliedFuzzyRule 

13.  For  each  fuzzy_rule  in  the  Fuzzy_rules 

14.  Begin 

15.  Y  <-  ApplyFuzzyRules  (D,I,F,C,  Fuzzy_rule) 

16.  Y  <-  AggregateUsingMoM(Y) 

17.  End  for 

18.  R  <-  ComputeReliabilityFromDefuzzfiation  (Y) 

19.  End  for 

In  the  algorithm,  the  first  few  steps  are  for  deriving  AVS 
reliability  metrics  using  IT  AD  information.  The  details  of 
the  derivation  are  discussed  in  earlier  sections.  In  this 
section,  we  describe  the  prediction  portion  of  the  algorithm. 

We  predict  AVS  reliability  based  on  AVS  reliability 
metrics  (‘D’,  T,  ‘C’,  and  ‘F’).  The  prediction  is  performed 
using  an  approximation  process.  Because  of  the  vagueness  in 
the  metrics  values,  approximation  has  to  be  done  using 
imprecise  data.  We  use  fuzzy  logic  [12]  for  this  situation. 
Fuzzy  logic  is  a  soft  computing  heuristic  technique  based  on 
the  fuzzy  sets  theory  [11].  Refer  to  [13]  for  additional 
information  on  fuzzy  logic. 

Fuzzy  set  of  elements  have  different  truth  values 
(membership  grades)  ranging  between  0  and  1.  For  example, 
a  fuzzy  set  of  very  tall  people  can  be  represented  as  S=  {7’, 
7’ 5”,  6’ 5”,  6’,  and  5’},  using  expert  knowledge,  the  grades 
of  membership  for  this  set  can  be  defined  as  0.9,  1,  0.8,  0.7, 
and  0.3.  In  this  example,  ‘very  tall  people”  is  a  linguistic 
term  to  represent  a  set  of  people’s  heights. 

If  X  is  a  set  denoted  by  Y,  then  a  fuzzy  set  S  in  X  is  a  set 
of  ordered  pairs  i.e.,  S  =  {(x,  pY(x))  |  x  8  X},  e.g.,  S  =  {(7’, 
0.9),  (7’5”,  1),  (6’5”,  0.8),  (6’,  0.7),  (5’,  0.3)}. 

After  the  metric  values  are  calculated,  the  algorithm  uses 
the  following  main  steps  to  predict  AVS  reliability  as  a 
number. 

1 .  Fuzzify  inputs 

2.  Apply  fuzzy  rules 

3.  Defuzzify  results 

We  explain  our  algorithm  using  an  example.  Assume  the 
ITAD  are  investigated  and  the  values  of ‘D’,  ‘I’,  ‘C’,  and  ‘F’ 
are  calculated  to  be  ‘D’  =  0.225,  ‘I’  =  0.45,  ‘C’  =  0.4,  and 
‘F’  =  0.26. 

The  fuzzification  or  fuzzify  step  assigns  a  specific 
membership  to  each  crisp  input.  The  membership  is  a 
membership  function  and  a  membership  grade.  We  suggest 
using  a  triangular  membership  function  for  each  input 
(Figure  2  through  Figure  5).  A  membership  function  is  a  plot 
of  points  which  reflect  how  each  input  point  from  the  input 
space  is  mapped  to  membership  grades  ranging  between  0 
and  1. 
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Figure.2  Data  Handling  (D)  fuzzy  membership  functions 


Figure.3  Interoperability  (I)  fuzzy  membership  functions 


in  put  v □  ria  b  le  "  C  □  nflgurab  ility" 

Figure.5  Configurability  (C)  fuzzy  membership  functions 


Table  .2  Linguistic  triangular  membership  variables 


* 

Linguistic 

terms 

D 

Range 

Range 

C 

Range 

F 

Range 

ReHiabiUiy 

Range 

L 

0.0  - 0.3 

0.0- 1.0 

0.0-  1.0 

0.0 -0.4 

0.0- 0.3 

LM 

0.2  -0.S 

0.8  -  1.5 

0.8-  3.0 

0.2- 0.8 

M/A 

M 

0.5  -  1.0 

1.4-  2.5 

2.5  -  4.0 

0.5  -1.0 

0.2- 0.6 

MH 

0.9  -  1.5 

2.1-  3.0 

N/A 

0.8  -  1.2 

N/A 

H 

1.4  -  3.0 

2.8  -  8.0 

3.5 -8.0 

1.2  -  6.0 

0.5  -  1.0 

In  Table  2,  the  ‘Linguistic  terms’  column  represents  a 
membership  function’s  labels.  The  ‘D’  value  of  0.225 
belongs  to  two  functions  i.e.,  ‘L’  and  ‘LM’.  The 

fuzzification  (Figure  6)  process  determines  an  appropriate 
membership  assignment  for  it. 


Figure. 4  Fault  Handling  (F)  fuzzy  membership  functions 


Crisp  Values  for  rDr 

Figure.6  Fuzzification  process 

As  shown  in  Figure  6,  0.225  has  a  membership  grade  pLM 
=  0.11  for  the  ‘LM’  membership  function  and  a  membership 
grade  pL  =  0.3  for  the  ‘L’  membership  function.  In  this 
situation,  the  fuzzification  process  assigns  a  maximum  of 
two  membership  grades  i.e.,  max  (pLM,  Pl)-  For  0.225,  the 
‘L’  membership  function  with  a  membership  grade  of  0.3  is 
the  maximum.  If  ‘L’  had  no  overlapping  with  ‘LM’,  then 
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there  is  no  need  for  a  maximum  function  check,  and  a  pL 
value  of  0.3  will  be  assigned.  This  fuzzified  number  is  called 
a  fuzzy  number.  Similarly  T,  ‘F’,  and  ‘C’  inputs  can  be 
fuzzified. 

In  the  next  step  of  the  algorithm,  all  the  fuzzy  inputs  will 
be  verified  against  expert  knowledge  based  fuzzy  rules 
(Figure  7).  This  process  is  called  a  fuzzy  reasoning  process 
also  known  as  a  fuzzy  inference.  Every  rule  is  applied  to  all 
the  fuzzy  inputs  and  the  results  from  each  rule  are 
aggregated  using  a  “maximum  of  mean  value”  function. 


1 .  If  (D  is  L)  and  (I  is  L)  and  (F  is  L)  and  (C  is  L)  then  (Reliability  is  H)  CD 

2.  If  CD  is  L)  and  (I  is  LM)  and  (F  is  L)  and  (C  is  L)  then  (Reliability  is  H)  (1 ) 

3.  If  (D  is  L)  and  (I  is  L)  and  (F  is  LM)  and  (C  is  L)  then  (Reliability  is  H)  (1 ) 

4.  If  (D  is  L)  and  (I  is  L)  and  (F  is  L)  and  (C  is  M)  then  (Reliability  is  H)  (1 ) 

5.  If  (D  is  LM)  and  (I  is  L)  and  (F  is  L)  and  (C  is  L)  then  (Reliability  is  H)  (1 ) 

6.  If  (D  is  LM)  and  (I  is  LM)  and  (F  is  L)  and  (C  is  L)  then  (Reliability  is  M)  (1 ) 

7.  If  (D  is  LM)  and  (I  is  L)  and  (F  is  LM)  and  (C  is  L)  then  (Reliability  is  M)  (1 ) 

S.  If  CD  is  LM)  and  (I  is  LM)  and  (F  is  L)  and  (C  is  L)  then  (Reliability  is  M)  (1 ) 

9.  If  (D  is  LM)  and  (I  is  L)  and  (F  is  L)  and  (C  is  M)  then  (Reliability  is  M)  (1 ) 

1 0.  If  (D  is  LM)  and  (I  is  L)  and  (F  is  LM)  and  (C  is  M)  then  (Reliability  is  M)  (1 ) 

1 1 .  If  CD  is  M)  and  (I  is  L)  and  (F  is  L)  and  (C  is  L)  then  (Reliability  is  M)  (1 ) 

1 2.  If  (D  is  MH)  or  (I  is  H)  or  (F  is  H)  or  (C  is  MH)  then  (Reliability  is  L)  (1 ) 

1 3.  If  (D  is  H)  or  (I  is  MH)  or  (F  is  MH)  or  (C  is  H)  then  (Reliability  is  L)  (1 ) 

Figure.7AVS  reliability  prediction  fuzzy  rules 

Fuzzy  rules  are  expressed  in  linguistic  statements  and  they 
represent  how  the  algorithm  decides  to  assign  a  fuzzy  input 
to  a  fuzzy  output  space.  For  example,  in  rule  #1  (Figure  7), 
“if  (D  is  F)  and  (I  is  F)  and  (C  is  F)  then  the  reliability  is  H,” 
F  and  H  are  linguistic  labels  used  to  represent  membership 
functions.  When  the  ‘and’  operator  is  used  in  a  rule,  the 
result  of  the  rule  application  will  get  the  minimum 
membership  value  out  of  all  the  fuzzy  inputs  used  in  the 
rule.  For  example,  assume  the  following  membership 
grades/values  are  assigned  based  on  the  fuzzify  step  for  each 
input  (‘D’,  T,  ‘F’,  ‘C’):  pD  =  0.3,  \ii  =  0.4,  pF  =  0.2,  and  pc 
=  0.1.  With  these  membership  grades,  when  the  rule#l  is 
applied,  the  result  will  be  as  follows: 

D  A  I  A  F  A  C  =  min  (pdPjPfPc)  (8) 

When  the  ‘or’  operator  is  used  in  a  rule,  the  result  of  the 
rule  application  will  get  the  maximum  membership  value  out 
of  all  the  fuzzy  inputs  used  in  the  rule.  For  example,  assume 
the  following  membership  grades/values  are  assigned  based 
on  the  fuzzify  step  for  each  input  (‘D’,  ‘I’,  ‘F’,  ‘C’):  pD  = 
0.3,  Hi  =  0.4,  pF  =  0.2,  and  pc  =  0.1.  With  these  membership 
grades,  when  the  rule#  12  is  applied,  the  result  will  be  as 
follows: 

D  AI  AF  AC  =  max  (pD  \i\ Pf  Pc)  (9) 


From  (8),  the  result  of  the  rule#l  is  min  (0.3  0.4  0.2  0.1)  = 
0.1.  From  (9),  the  result  of  the  rule  #12  is  min  (0.3  0.4  0.2 
0.1)  =  0.4.  Similarly  all  the  rules  will  be  applied  and  a 
resulting  output  distribution  is  obtained  (Figure  8). 


0  1 
Figure.8  Output  distribution 

Defuzzification  or  defuzzify  is  the  next  step  in  the 
algorithm.  In  this  step,  the  output  distribution  obtained  from 
the  previous  step  is  aggregated  and  a  mean  of  maximum 
(MOM)  function  is  applied  to  it  to  get  a  crisp  output  number. 
A  detailed  explanation  of  MOM  defuzzification  process  is 
found  in  [14].  Figure  9  shows  AVS  reliability  output 
membership  functions.  Using  the  output  membership 
functions,  the  MOM  process  maps  a  crisp  output  number. 
The  number  obtained  from  the  defuzzification  process  is  the 
AVS  reliability  prediction  number.  This  number  is  the 
predicted  probability  that  the  AVS  will  work  defect-free.  For 
example,  if  AVS  reliability  prediction  number  is  1,  then  it 
means  an  AVS  is  100%  defects-free.  If  the  number  is  0,  then 
the  AVS  is  full  of  defects.  If  the  number  is  0.5,  then  the 
AVS  is  50%  defect-free.  Figure  10  shows  the  entire  fuzzy 
logic  process  to  obtain  AVS  reliability  prediction  number. 
Based  on  the  example  dataset,  the  predicted  AVS  reliability 
number  is  0.615  (Figure  10). 

Based  on  the  current  AVS  reliability  number  obtained 
during  a  given  development  phase,  project  managers  can 
take  corrective  measures  to  improve  the  current  development 
situation  by  planning  to  capture  missing  details.  Higher  the 
predicted  AVS  reliability  number,  lesser  the  probability  of 
defects. 


0  0.1  0.2  0.3  0.4  0.3  0.6  0.7  0.3  0.9  1 


d  utp  ut  va  ria  ble  ^Relia  bility^ 

Figure.9  AVS  reliability  Fuzzy  membership  functions 
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Figure.10  AYS  reliability  Fuzzy  membership  functions 


Z 
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CONCLUSION 

We  introduced  the  AVS  reliability  prediction  metrics, 
which  are  simple  to  use  so  that  a  person  with  ordinary 
computer  skills  can  investigate  IT  AD  and  collect  data  for 
calculating  metrics  values.  The  AVS  reliability  prediction 
algorithm  is  simple  and  a  tool  can  be  developed  to  perform 
predictions.  Since  our  research  is  in  its  initial  stages,  we  are 
in  the  process  of  validating  and  improving  our  work  on  a 
practical  AVS  development  project 

DISCLAIMER 

Disclaimer:  Reference  herein  to  any  specific  commercial 
company,  product,  process,  or  service  by  trade  name, 
trademark,  manufacturer,  or  otherwise,  does  not  necessarily 
constitute  or  imply  its  endorsement,  recommendation,  or 
favoring  by  the  United  States  Government  or  the 
Department  of  the  Army  (Do A).  The  opinions  of  the 
authors-  expressed  herein  do  not  necessarily  state  or  reflect 
those  of  the  United  States  Government  or  the  DoA,  and  shall 
not  be  used  for  advertising  or  product  endorsement  purposes. 
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